[Previous] [Next] [Index] [Thread]

Re: Security/Privacy of Certificates in Netscape 3.0 (fwd)

FYI: This is long and if you aren't interested in certification
I would suggest you delete. I just want to set the record re: how
Virutal Communities are trusted in the Xcert model and how sensitive
client information is secured (in the Xcert model)


On Thu, 18 Jul 1996, Jeff Weinstein wrote:

> Date: Thu, 18 Jul 1996 02:20:29 -0700
> From: Jeff Weinstein <jsw@netscape.com>
> To: www-security@ns2.rutgers.edu
> Subject: Re: Security/Privacy of Certificates in Netscape 3.0
> 
> Gene Ingram wrote:
> > I just got a free certificate from Verisign for Netscape and now
> > wonder if anyone can use a method to query my certificate in
> > similar fashion to previous bugs where a user could query the
> > email address?  The Verisign certificate contains your name,
> > address, and level 2 even contains your SOCIAL SECURITY NUMBER
> > and BIRTHDATE among other sensitive info.
> > 
> ..stuff deleted...
> 
>   In the current beta, when you connect to a web site with SSL,
> and the site requests client authentication, the user is prompted
> to select a certificate to send, and can cancel the connection
> at this time.
> 
>   The final release of 3.0 will have several more options for
> choosing a certificate to send when a site requests client auth.
> The three options are:
> 
> ..stuff deleted...

The Xcert line of products allows certificate issuers to apply access
control to portions of the user information that are above and beyond the
X.509 certificate. We do not encourage issuers to place non-essential
information in the certificate, we encourage useing the certificates as
POINTERS to information that *may* be obtained seperately over an SSL-LDAP
connection. 

Issuers can place ACLs on the information, which is accessed only by
client-authenticated SSL LDAP, allwoing them to control who (or who
doesn't) have access to the extended information (if anyone does at all). 

In such a scenario (where no sensitive information is stored in the X.509
but it is used a a ptr to an access-controlled db), issuers should publish
and audit the machanisms by which someone might gain access to the
extended information, which is really the CA policy that applies to 
issueing the SSL-LDAP client certs. For all intensive purposes, we 
don't see many CA's right now allowing access to certificate user 
information, but the flexibility of this mechanism allows issuers to
do much more than just issue certs.

So for instance, if a certificate issuer (may or may not be a certificate
you ahve to PAY for) asks the user for additional information, the user
must be informed of the issuer's policy in regards to access to that
extended information. We only allow access to the extended information via
SSL-LDAP, so you merely need to know what vetting process your issuer is
applying to the practise of issuing certs to obtain the extended
information (the SSL-LDAP clients), if they allow anyone to access it at 
all. 

We try to emulate real-world scenarios in this manner. When you join a
tennis club, and they ask you for your address, you might ask them what
they want it for. They might tell you that they don't give it out to
mailing lists, and that it is only used for the monthly newsletter. It is 
up to you to decide whether you trust their information policy.

This is where companies like Verisign could really make a difference in
the multiple CA arena. By auditing vetting processes and giving "stamps of
approvals" that would say: "Organization X really does do what
organization X's policy says they do", it will give a lot of consumer
credibility to vetting processes. This is not to say that is is required,
but that it would prove useful. I would probably say that you normally
don't call up the BBB everytime you give your address out, or scutinize
every organization your give your SIN number to, but it would be nice to
have the option and the comfort to know that someone out there audits
vetting practices. Or even better (maybe going too far here) legislation
that would bind CA's to their policies. Again, this is not needed in most
scenarios, of the Virtual Community type, weher you are issued a cert by a
private site or something like that, where it is not used for the
much-fabled "EC" :-)

By authenticating db lookups pertaining to user information, it provides a
second scale of flexibility when it comes to management. For instance, on
our server, currently anyone with an LDAP client may query for the
standard, x.509 DN information and get someone's certificate back. But all
queries for extended information are controlled by cliant-auth SSL LDAP. A
perfect example is that even though you are allowed to create your own CA
certs on the site, and you can query via normal LDAP for a CA cert that
you created, you can't do a search for your CA's private key unless you
have a client cert (for the SSL LDAP connection) that would allow you to,
of which none exist, except the one that the HTTP server is useing (which
is the SSL-LDAP client in this case). Note that since the HTTP server is 
also secured, it is not a problem: our demo is just that, a DEMO, most 
people will not have certify-on-the-fly requirements. 

We use this methodology to store user-specific information, rahter than
the cumbersome, kludgey practise of useing the extended fields, because in
a cross-autheticated scenario most people won't know how to interpret the
extended fields other than simply know 'critical' or 'non-critical'. And
you also don't have to worry about passing it around (eg I might not want
everyone to know I am from Vancouver - which incidentally is NOT an
extended field, I just want them to know that I am Pat Richard). 

> 
>   The whole point of the Class 2 certificate is to verify your
> identity.  While verisign uses information such as your social
> security number and drivers license number to verify your identity,
> they do not include that information in your certificate.
> 
>   If you are uncomfortable giving them all of this information,
> you can get a class 1 certificate, which only requires your
> e-mail address.
> 
> 	--Jeff
> 
> -- 
> Jeff Weinstein - Electronic Munitions Specialist
> Netscape Communication Corporation
> jsw@netscape.com - http://home.netscape.com/people/jsw
> Any opinions expressed above are mine.
> 

--
Pat Richard    /    patr@xcert.com
----
Run your own CA and secure your Virtual Community:
	http://www.xcert.com

"Security without Big Brother"